.NET en open source : Microsoft transfère Mono à WineHQ
Le 29 août à 17h08
2 min
Logiciel
Logiciel
Le projet Mono, framework open source destiné à la mise en œuvre de la plateforme de développement .NET de Microsoft dans des environnements autres que Windows, aurait-il trouvé son ultime refuge ? Microsoft, qui assurait la maintenance du projet depuis le rachat de Xamarin en 2016, vient d’annoncer son transfert à WineHQ, l’équipe en charge du développement de Wine.
« Nous tenons à souligner que le projet Mono a été la première implémentation de .NET sur Android, iOS, Linux et d’autres systèmes d’exploitation », salue Microsoft dans un message publié sur le site dédié, avant de rappeler que l’activité du projet s’est considérablement ralentie, victime indirecte de l’évolution des environnements de développement multiplateformes. La dernière version majeure remonte en effet à 2019, et Mono ne reçoit plus depuis que des correctifs, dont le dernier a été diffusé en février dernier.
Dans le cadre de ce transfert, WineHQ assure donc maintenant la responsabilité du projet, dont les sources sont disponibles sur son Gitlab, tandis que les dépôts et binaires historiques devraient quant à eux être archivés. Dans la mesure où WineHQ, comme Microsoft, exploitent déjà chacun leur propre fork, plus moderne, de Mono, l’intendance ne devrait revêtir qu’une portée symbolique.
Lancé en 2001 par Miguel de Icaza (par ailleurs créateur de GNOME), Mono a connu une histoire tumultueuse, sur fond de rachats successifs et de controverses liées à de potentielles atteintes aux droits de la propriété intellectuelle de Microsoft, bien avant que ce dernier ne prenne la décision d’ouvrir .NET à l’open source.
Le 29 août à 17h08
Commentaires (36)
Abonnez-vous pour prendre part au débat
Déjà abonné ? Se connecter
Cet article est en accès libre, mais il est le fruit du travail d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles
Profitez d’un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 29/08/2024 à 17h10
Le 29/08/2024 à 17h13
Le 29/08/2024 à 17h21
Le 30/08/2024 à 17h07
Le 30/08/2024 à 22h52
Le 29/08/2024 à 17h29
Le 29/08/2024 à 17h35
Le 29/08/2024 à 17h50
Modifié le 29/08/2024 à 17h58
Le 29/08/2024 à 18h12
Le 30/08/2024 à 09h46
Le 29/08/2024 à 18h55
Des applications multiplateformes sont portées sous linux comme l'émulateur Ryujinx.
Mono est fourni avec wine (wine-mono) tout comme wine-gecko pour remplacer les closedsource .net (< 5.0) et ie.
Microsoft avec Azure Linux doit l'utiliser.
Le 29/08/2024 à 20h54
Le 29/08/2024 à 21h21
Mais c'est le cas aussi du logiciel de sauvegarde Duplicati.
Le 30/08/2024 à 09h45
Le 30/08/2024 à 09h44
Le 30/08/2024 à 10h28
Le 29/08/2024 à 22h37
Le 30/08/2024 à 09h03
Comme containeriser une VM pour faire croire qu'une appli monolithique de l'enfer est subitement "cloud native" ?
Le 30/08/2024 à 11h11
Au passage, un pod ne peut pas utiliser la puissance de calcul d'un cluster entier, un pod ne peut jamais excéder la capacité disponible du nœud sur lequel il tourne (dans un scénario où tu n'aurais pas toi-même mis des limites à la consommation de ressources du pod)
J'ai déjà eu un client avec ~200 microservices en .Net dans ce type de scénario.
La bonne pratique n'est pas de convertir des VM en pod, juste de déployer les applis dans des images dans un flux ci/cd. On ne gère pas des pods comme des VM et convertir des VM, même si c'est partiellement possible, en dit plus sur la qualité de l'architecture d'une entreprise qu'autre-chose.
Le 30/08/2024 à 11h33
Le 30/08/2024 à 15h24
Le 30/08/2024 à 15h46
Ou encore ceux qui disent "azy t'inquiète" en mettant leur BDD dessus et qui ont eu droit à une cellule de crise car ils avaient perdu toutes les données.
À trop prévenir que ça marchera pas, parfois je me dis qu'il vaut mieux les laisser expérimenter le skateboard dans l'escalier.
Modifié le 30/08/2024 à 17h35
Le 30/08/2024 à 14h46
Modifié le 04/09/2024 à 17h11
Le 29/08/2024 à 19h42
Le 29/08/2024 à 20h58
Après, c'est loin d'être étonnant. .Net Core (ou .Net 5 et supérieur) est la seule version de .Net encore en développement. Et cette version est portable.
Le .Net framework (dont la version officielle était limité à Windows) s'est arrêté en 4.8 et il n'y aura pas d'autres versions.
Mono n'a donc guère d'intérêt à continuer aujourd'hui.
Le 30/08/2024 à 03h25
Le mono, même en Core, mais c'est d'un ringard !...
Le 30/08/2024 à 11h17
Le 30/08/2024 à 03h57
Le 30/08/2024 à 09h03
Ce sont deux projets distincts, bien qu'ils présentent de nombreuses similarités. L'adoption de CoreCLR (qui est portable) comme implémentation de référence .Net par Microsoft a simplement rendu Mono "quasiment désué" (Mono était très utile par sa portabilité, devenue "inutile" avec CoreCLR car déjà présente).
Le 30/08/2024 à 14h55
Malheureusement ... ils l'ont cassé 3 fois minimum: dotnet 4, dotnet core, dotnet 6.
Soit carrément sur le format d'objet, soit sur la lib.
C'est carrément l'enfer si vous pensez que .net standard est utilisable dans les 2 mondes (core et framework): c'est vrai, du moment que vous ne faites pas de chargement à la volée. Car dans ce cas, vous allez mixer au pif des objets des 2 environnement d'exécution et les liens ne se feront pas...
Bref, c'est bien, les langages sont cool, les possibilités intéressantes, les outils déments, mais plein de promesses ne sont pas tout à fait tenues, on est loin de java "write once, run everywhere".
Sans compter qu'ils n'ont pas su le pousser assez pour aller vers du platform agnostic, notamment au moment de swindows phones.
Modifié le 30/08/2024 à 20h39
(Faites pas gaffe, j'y pige que chique en programmation... Vous pourriez me dire que que Macron a été conçu en .NET par Brigitte, que ce serait du pareil au même...)
(Tout ça, juste pour avoir l'air d'exister... De plus en plus navrant... Désolé... )
Le 30/08/2024 à 17h37
Le 04/09/2024 à 11h29